1. Field Of The Invention
This invention generally relates to telecommunications systems and, more particularly, to a system and method for managing hardware and software processes to control Transmission and reception of video broadcasts.
2. Background
Systems for the transmission and reception of the video broadcasts are generally known. Video broadcasts are typically transmitted from a broadcast site to a reception site by way of a satellite link or relay. The broadcast site typically broadcasts a particular program by sending an electronic signal to a particular satellite which services the reception site. The electronic signal can comprise both video and data information. The electronic signal may be received from the satellite by an integrated receiver/decoder ("IRD") located at the reception site.
The reception site typically services one or more subscribers which are linked to the reception site by a suitable transmission medium. The transmission medium can be, for example, coaxial cable, optical fiber or a combination of both. Once the signal has been received at the reception site from the satellite, it is forwarded to one or more of the subscribers.
Typically, both video and data information are transmitted from the broadcast site to the reception site. The data information may include decryption information used by the IRD to determine if the IRD is eligible to receive the video information being transmitted. The IRD compares the decryption information it receives with decryption keys previously stored in its memory. If a match occurs, the IRD will decrypt the video information and transmit a decoded signal to one or more designated subscribers.
A typical IRD contains 32 physical slots capable of storing decryption keys. This means an IRD can receive 1 of 32 possible broadcasts based upon the decryption keys it uses to decrypt the video transmission. Also, the IRD can be configured to receive a program command which instructs the IRD as to which slot to use to obtain the decryption keys needed to decrypt a particular video broadcast. By changing this program command to designate a different slot, the IRD can be tuned to a different frequency to receive a different video broadcast.
Telecommunication systems of the foregoing type suffer from several drawbacks. Such systems do not provide the ability to easily load decryption keys into IRD slots. Also, such systems do not allow an operator to quickly change the broadcast being received by an IRD by way of altering the program command. In the past, IRDs have been controlled by a personal computer ("PC")-based system. One such system used a Paradox database to store management information. The entire system ran on PCs in an MS Windows environment. However, four PCs were needed to run the entire system and each PC was dedicated to a distinct component of the system. Therefore, a system operator would have to move from one PC to another depending on the task he or she wished to perform. Also, the PCs were not networked together. If one PC crashed, then that part of the system was unavailable for use until the PC was replaced or repaired. Thus, the system was "single-threaded." Because the system was not integrated, a code switch was necessary to direct commands from one PC as opposed to another. For example, the program command could not be sent at the same time that other IRD commands were being transmitted. Thus, the code switch was necessary to control which PC could actually transmit a command over the satellite network at a given time. Another problem was that the Paradox database lacked referential integrity. For example, information relating to a particular IRD could be removed from the Paradox database without warning of an integrity violation. Further, only selected information was maintained in the Paradox database. The information structure was inflexible and IRDs could not be classified according to their current state (e.g., authorized, de-authorized, sold, etc.). Another drawback related to management reports, which had to be prepared manually. Also, audit trails of worked performed (e.g., commands sent, IRDs authorized, etc.) were nonexistent. Further, system functions were not based upon user IDs or functional roles. Therefore, system security was limited. Moreover, a control operator could not group commands and execute them as a single command to, for example, one or more of the IRDs. The operator did not have the ability to schedule commands for execution or to schedule changes to the program command. Among other problems, these drawbacks resulted in time-consuming and error-prone creation of broadcast schedules. For example, it was not uncommon that four days were required to build a monthly broadcast schedule for a single customer. Other problems with prior telecommunication systems are known to exist.